This invention relates generally to a system and method for planning and scheduling work flow and processes for reconfigurable production operations and equipment, which enables a service technician to select and use diagnostic jobs, for example feeding a sheet to the module being serviced in a printer system, while the system is otherwise operating in normal mode on fobs around the off-line module.
Reconfigurable production systems increasingly consist of multiple parallel, alternative modules that are connected through flexible paths and even loops. Consequently, such systems are expected to offer a multitude of alternative operations (or capabilities) to produce the same outputs. For example, a modular printing system may consist of several identical, parallel printers connected through flexible paper paths that feed to and collect from these printers. For previous, in-line systems, the entire system was usually stopped when one of its modules went off-line, typically because of a fault, and a service technician could assume that the entire system was at their disposal during diagnostic and repair operations. With the types of parallel systems described above, it is desirable to continue using all available system capabilities by planning and scheduling around the off-line module as necessary, and at the same time interleaving diagnostic jobs as requested by the technician.
A reconfigurable production system may be modeled as a graph of connected modules, with each module described by a model of its structure and its capabilities. The structure is primarily the interface through with work units enter and exit, such as entry and exit ports, plus any internally used resources. A capability is an operation that accepts work units at entry ports, processes them, and moves them to exit ports. (Entry and exit ports here refer to mechanical interfaces, such as slots or trays, as well as computer interfaces. A port may serve as both entry and exit port.) Operation of such a system has been modeled as a sequence of capability executions as work units move along valid paths in the graph from module to module.
An example for a reconfigurable production system is a modular printer, with modules such as feeders, mark engines, paper transports, inverters, etc. There, the work units are sheets and images. A simple paper transport module has an entry port, an exit port, and a single capability, to move a sheet of paper from its entry port to its exit port. An inverter module has one entry port, one exit port, and two capabilities, one to invert a sheet of paper and one to bypass the inversion mechanism. A mark engine transfer module has two entry ports (one for sheets and one for images), one exit port (for marked sheets), and one capability, to print the image onto the sheet. A sample resource in all of these modules is the space occupied by the sheet, which may only be occupied by one sheet at a time. Other examples of reconfigurable production systems are assembly lines, for example for the assembly or packing of computer parts, and automated analytic systems, such as blood sample analysis machines. In these various production systems, work units may be sheets of paper, electronic files, computer parts, semiconductor wafers, blood sample trays, any parts or composites of these, or other physical or electronic objects being processed by production systems. Transport mechanisms may be conveyor belts or robotic arms or any other devices or functions for moving work units.
Module capabilities may be composed to system capabilities by incrementally unifying work unit and time variables of output and input events at connected modules along valid paths in the system graph. For example, if a module's exit port is connected to another module's entry port, any capability producing work units for the first module's exit port potentially can be composed with any capability consuming work units from the second module's entry port. Unification of work unit and time variables ensures the consistency of attribute and time constraints.
A scheduler for such systems receives a stream of jobs, each consisting of a sequence of desired work units to be produced at some final exit port of the system. Each desired work unit is described by a work unit variable with attribute constraints. This is used to select a suitable system capability that can produce the desired work unit by unifying the desired work unit variable with the work unit variables of system capabilities producing work units for the desired exit port. As system capabilities for the desired work units in the jobs are found, their time and resource constraints are posted to the constraint store, and the constraints are solved in order to find time values for the various module capabilities producing the desired work units. The selected module capabilities plus the time values are then sent to the modules so that they can execute the corresponding operations at the designated times.
For the purposes herein, diagnostic job is defined as a job that requires nonstandard system capabilities. Non-standard system capabilities are, for example, capabilities that do not start or end in the usual entry or exit ports, such as feeders and finishers in a printing system, and capabilities that use unusual combinations of operations, such as moving a sheet through a transfer component without marking an image on it, which is usually not permitted.
The approach to system control described above has no generic way to plan and schedule diagnostic jobs in parallel with regular jobs. One reason for this is that even regular jobs are generally not interleaved and thus no simple provision for including diagnostic jobs in parallel is available. Another reason is that the existing approach requires capabilities to start and end at regular entry or exit ports of system capabilities. The approach also does not have any provisions to execute diagnostic jobs while the rest of the system is running normally. Instead, usually the entire system is taken down if a module is off-line and being serviced.
This approach proves unsatisfactory for systems with many alternative, parallel system capabilities. With these systems, it is desirable to continue using all available system capabilities by planning and scheduling around an off-line module as necessary, while concurrently running diagnostic jobs as requested.